home *** CD-ROM | disk | FTP | other *** search
/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / mini / Software-Building < prev    next >
Text File  |  1997-12-28  |  26KB  |  587 lines
  1.   Building Software Packages for Linux
  2.   Mendel Leo Cooper <mailto:thegrendel@theriver.com>
  3.   http://personal.riverusers.com/~thegrendel/
  4.   v1.52, 27 December 1997
  5.  
  6.   This is a comprehensive guide to building "generic" UNIX software dis¡
  7.   tributions under Linux.
  8.  
  9.   1.  Introduction
  10.  
  11.   Many software packages for the various flavors of UNIX, including
  12.   Linux, are distributed as compressed archives of source files.  The
  13.   same package may be "built" to run on different target machines, and
  14.   this saves the author of the software from having to produce multiple
  15.   distributions. A single distribution of a software package may thus
  16.   end up running, in various incarnations, on an Intel box, a DEC Alpha,
  17.   a RISC workstation, or even a mainframe.  Unfortunately, this puts the
  18.   responsibility of actually "building" the software on the end user,
  19.   the de facto "system administrator", the fellow sitting at the
  20.   keyboard...  you.  Take heart, though, the process is not nearly as
  21.   terrifying or mysterious as it seems, as this guide will demonstrate.
  22.  
  23.   2.  Getting Started
  24.  
  25.   You have downloaded or otherwise acquired a software package.  Most
  26.   likely it is archived (tarred) and compressed (gzipped), in .tar.gz or
  27.   .tgz form. First copy it to a working directory. Then untar and gunzip
  28.   it. The appropriate command for this is tar xzvf filename, where
  29.   filename is the name of the software file, of course.  The de-
  30.   archiving process will usually install the appropriate files in
  31.   subdirectories it will create.  Note that if the package name has a .Z
  32.   suffix, it will require uncompress PACKAGENAME, then tar xvf
  33.   PACKAGENAME rather than the above procedure.
  34.  
  35.   Sometimes the archived file must be untarred and installed from the
  36.   user's home directory, or perhaps in a certain other directory, as
  37.   specified in the package's config info.  Should you get an error
  38.   message attempting to untar it, this may be the reason. Read the
  39.   package docs, especially the README and/or Install files, if present,
  40.   and edit the config files and/or Makefiles as necessary, consistent
  41.   with the installation instructions. Note that you would not ordinarily
  42.   alter the Imake file, since this could have unforseen consequences.
  43.   Some software packages permit automating this process by running make
  44.   install to emplace the binaries in the appropriate system areas.
  45.  
  46.   Occasionally, you may need to update or incorporate bug fixes into the
  47.   unarchived source files using a patch file that lists the changes.
  48.   The doc files and/or README file will inform you should this be the
  49.   case. The normal syntax for invoking Larry Wall's powerful patch
  50.   utility is patch < patchfile.
  51.  
  52.   You may now proceed to the build stage of the process.
  53.  
  54.   3.  Using Make
  55.  
  56.   The Makefile is the key to the build process. In its simplest form, a
  57.   Makefile is a script for compiling or building the "binaries", the
  58.   executable portions of a package. The Makefile can also provide a
  59.   means of updating a software package without having to recompile every
  60.   single source file in it, but that is a different story (or a
  61.   different article).
  62.  
  63.   At some point, the Makefile launches cc or gcc. This is actually a
  64.   preprocessor, a C (or C++) compiler, and a linker, invoked in that
  65.   order.  This process converts the source into the binaries, the actual
  66.   executables.
  67.  
  68.   Invoking make usually involves just typing make. This generally builds
  69.   all the necessary executable files for the package in question.
  70.   However, make can also do other tasks, such as installing the files in
  71.   their proper directories (make install)and removing stale object files
  72.   (make clean).  Running make -n permits previewing the build process,
  73.   as it prints out all the commands that would be triggered by a make,
  74.   without actually executing them.
  75.  
  76.   Only the simplest software uses a generic Makefile. More complex
  77.   installations require tailoring the Makefile according to the location
  78.   of libraries, include files, and resources on your particular machine.
  79.   This is especially the case when the build needs the X11 libraries to
  80.   install. Imake and xmkmf accomplish this task.
  81.  
  82.   An Imakefile is, to quote the man page, a "template" Makefile. The
  83.   imake utility constructs a Makefile appropriate for your system from
  84.   the Imakefile. In almost all cases, however, you would run xmkmf, a
  85.   shell script that invokes imake, a front end for it.  Check the README
  86.   or INSTALL file included in the software archive for specific
  87.   instructions.  Read the imake and xmkmf man pages for a more detailed
  88.   analysis of the procedure..
  89.  
  90.   Be aware that xmkmf and make may need to be invoked as root,
  91.   especially when doing a make install to move the binaries over to the
  92.   /usr/bin or /usr/local/bin directories.  Using make as an ordinary
  93.   user without root privileges will likely result in write access denied
  94.   error messages because you lack write permission to system
  95.   directories. Check also that the binaries created have the proper
  96.   execute permissions for you and any other appropriate users.
  97.  
  98.   Invoking xmkmf uses the Imake file to build a new Makefile appropriate
  99.   for your system. You would normally invoke xmkmf with the -a argument,
  100.   to automatically do a make Makefiles, make includes, and make depend.
  101.   This sets the variables and defines the library locations for the
  102.   compiler and linker.  Sometimes, there will be no Imake file, instead
  103.   there will be an INSTALL or configure script that will accomplish this
  104.   purpose. Note that if you run configure, it should be invoked as
  105.   ./configure to ensure that the correct configure script in the current
  106.   directory is called. In most cases, the README file included with the
  107.   distribution will explain the install procedure.
  108.  
  109.   It is usually a good idea to visually inspect the Makefile that xmkmf
  110.   or one of the install scripts builds. The Makefile will normally be
  111.   correct for your system, but you may occasionally be required to
  112.   "tweak" it or correct errors manually.
  113.  
  114.   Your general installation procedure will therefore be:
  115.  
  116.   ╖  Read the README file and other applicable docs.
  117.  
  118.   ╖  Run xmkmf -a, or the INSTALL or configure script.
  119.  
  120.   ╖  Check the Makefile.
  121.  
  122.   ╖  If necessary, run make clean, make Makefiles, make includes, and
  123.      make depend.
  124.  
  125.   ╖  Run make.
  126.  
  127.   ╖  Check file permissions.
  128.  
  129.   ╖  If necessary, run make install.
  130.  
  131.   4.  Troubleshooting
  132.  
  133.   If xmkmf and/or make succeeded without errors, you may proceed to the
  134.   ``next section''.  However, in "real life", few things work right the
  135.   first time.  This is when your resourcefulness is put to the test.
  136.  
  137.   4.1.  Link Errors
  138.  
  139.   ╖  Suppose make fails with a Link error: -lX11: No such file or
  140.      directory, even after xmkmf has been invoked. This may mean that
  141.      the Imake file was not set up properly. Check the first part of the
  142.      Makefile for lines such as:
  143.  
  144.        LIB=            -L/usr/X11/lib
  145.        INCLUDE=        -I/usr/X11/include/X11
  146.        LIBS=           -lX11 -lc -lm
  147.  
  148.   The -L and -I switches tell the compiler and linker where to look for
  149.   the library and include files, respectively. In this example, the X11
  150.   libraries should be in the /usr/X11/lib directory, and the X11 include
  151.   files should be in the /usr/X11/include/X11 directory. If this is
  152.   incorrect for your machine, make the necessary changes to the Makefile
  153.   and try the make again.
  154.  
  155.   ╖  In a very few cases, running ldconfig as root may be the solution:
  156.  
  157.      # /etc/ldconfig -n /lib will update the shared library symbolic
  158.      links. This should not be necessary under normal circumstances.
  159.  
  160.   ╖  Yet another thing to try if xmkmf fails is the following script:
  161.  
  162.                 make -DUseInstalled -I/usr/X386/lib/X11/config
  163.  
  164.   ╖  Sometimes the source needs the older release X11R5 libraries to
  165.      build.  If you have the R5 libs in /usr/X11R6/lib (you were given
  166.      the option of having them when first installing Linux), then you
  167.      need only ensure that you have the links that the software needs to
  168.      build.  The R5 libs are named libX11.so.3.1.0, libXaw.so.3.1.0, and
  169.      libXt.so.3.1.0. You generally need links, such as libX11.so.3 ->
  170.      libX11.so.3.1.0. Possibly the software will also need a link of the
  171.      form libX11.so -> libX11.so.3.1.0.  Of course, to create a
  172.      "missing" link, use the command ln -s libX11.so.3.1.0 libX11.so, as
  173.      root.
  174.  
  175.   ╖  Some packages will require you to install updated versions of one
  176.      or more libraries. For example, the StarOffice suite from
  177.      StarDivision GmbH is notorious for needing a libc version 5.4.4 or
  178.      greater.  As root, you would need to copy one or more libraries to
  179.      the appropriate directories, remove the old libraries, then reset
  180.      the symbolic links.
  181.  
  182.      Caution: Exercise extreme care in this, as you can render your
  183.      system nonfunctional if you screw up.
  184.  
  185.      You can usually find updated libraries at Sunsite
  186.      <ftp://sunsite.unc.edu>.
  187.  
  188.   4.2.  Other Problems
  189.  
  190.   ╖  An installed Perl or shell script gives you a No such file or
  191.      directory error message. In this case, check the file permissions
  192.      to make sure the file is executable and check the file header to
  193.      ascertain whether the shell or program invoked by the script is in
  194.      the place specified.  For example, the scrip may begin with:
  195.  
  196.        #!/usr/local/bin/perl
  197.  
  198.   If Perl is in fact installed in your /usr/bin directory instead of the
  199.   /usr/local/bin one, then the script will not run.  There are two meth¡
  200.   ods of correcting this. The script file header may be changed to
  201.   #!/usr/bin/perl, or a symbolic link to the correct directory may be
  202.   added, ln -s /usr/bin/perl /usr/local/bin/perl.
  203.  
  204.   ╖  Some X11 software requires the Motif libraries to build.  The
  205.      standard Linux distributions do not have the Motif libraries
  206.      installed, and at present Motif costs an extra $100-$200 (though
  207.      the freeware Lesstif <http://www.lesstif.org/> also works in many
  208.      cases). If you need Motif to build a certain package, but lack the
  209.      Motif libraries, it may be possible to obtain statically linked
  210.      binaries. Static linking incorporates the library routines in the
  211.      binaries themselves.  This results in much larger binary files, but
  212.      the code will run on systems lacking the libraries.
  213.  
  214.   ╖  Running a configure script creates a strange Makefile, one
  215.      seemingly unrelated to the package you are attempting to build.
  216.      This means the wrong configure ran, one found somewhere else in
  217.      your path. Always invoke configure as ./configure to prevent this.
  218.  
  219.   ╖  Some programs require having setuid root, in order to run with root
  220.      privileges. The command to implement this is chmod u+s filename, as
  221.      root (note that the program must already be owned by root). This
  222.      has the effect of setting the setuid bit in the file permissions.
  223.      This issue comes up when the program accesses the system hardware,
  224.      such as a modem or CD ROM drive, or when the SVGA libs are invoked
  225.      from console mode, as in one particularly notorious emulation
  226.      package. If a program works when run by root, but gives access
  227.      denied error messages to an ordinary user, suspect this as the
  228.      cause.
  229.  
  230.      Warning: A program with setuid as root may pose a security risk to
  231.      your system. The program runs with root privileges and thus has the
  232.      potential for doing significant damage. Make certain that you know
  233.      what the program does, by looking at the source if necessary,
  234.      before setting the setuid bit.
  235.  
  236.   4.3.  Tweaking and fine tuning
  237.  
  238.   You may wish to examine the Makefile to make certain that the best
  239.   compilation options for your system are invoked. For example, setting
  240.   the -O2 flag chooses the highest level of optimization and the -fomit-
  241.   frame-pointer flag results in a smaller binary (though debugging will
  242.   then be disabled). Do not play around with this unless you know what
  243.   you are doing, and in any case, until after a trial build works.
  244.  
  245.   4.4.  Where to go for more help
  246.  
  247.   In my experience, perhaps 25% of applications build "right out of the
  248.   box". Another 50% or so can be "persuaded" to build with an effort
  249.   ranging from trivial to herculean. That still means a significant
  250.   number of packages will not build no matter what. Even then, the Intel
  251.   ELF and/or a.out binaries for these might possibly be found at Sunsite
  252.   <ftp://sunsite.unc.edu>, the TSX-11 archive <ftp://tsx-11.mit.edu> or
  253.   other places.  Perhaps the author of the software can supply the
  254.   binaries compiled for your particular flavor of machine.
  255.  
  256.   Note that if you obtain precompiled binaries, you will need to check
  257.   for compatibility with your system:
  258.  
  259.   ╖  The binaries must run on your hardware (i.e., Intel x86).
  260.  
  261.   ╖  The binaries must be compatible with your kernel (i.e., a.out or
  262.      ELF).
  263.  
  264.   ╖  Your libraries must be up to date.
  265.  
  266.   If all else fails, you may find help in the appropriate newsgroups,
  267.   such as comp.os.linux.x or comp.os.linux.development.  Once in a
  268.   while, though, you are just plain out of luck, but hey, it was fun
  269.   trying.
  270.  
  271.   5.  Final Steps
  272.  
  273.   Read the software package documentation to determine whether certain
  274.   environmental variables need setting (in .bashrc or .cshrc) and if the
  275.   .Xdefaults and .Xresources files need customizing.
  276.  
  277.   There may be an applications default file, usually named Xfoo.ad in
  278.   the original Xfoo distribution. If so, edit the Xfoo.ad file to
  279.   customize it for your machine, then rename (mv) it Xfoo and install it
  280.   in the /usr/lib/X11/app-defaults directory, as root.  Failure to do
  281.   this may cause the software to behave strangely or even refuse to run.
  282.  
  283.   Most software packages come with one or more preformatted man pages.
  284.   As root, copy the Xfoo.man file to the appropriate /usr/man directory
  285.   (man1 - man9), and rename it accordingly.  For example, if Xfoo.man
  286.   ends up in /usr/man/man4, it should be renamed Xfoo.4 (mv Xfoo.man
  287.   Xfoo.4).  By convention, user commands go in man1, games in man6, and
  288.   administration packages in man8 (see the man docs for more details).
  289.   Of course, you may deviate from this on your own system, if you like.
  290.  
  291.   Some packages will not install the binaries in the appropriate system
  292.   directories, that is, they are missing the install option in the
  293.   Makefile. Should this be the case, you can install the binaries
  294.   manually by copying the binaries to the usr/local/bin directory, as
  295.   root.
  296.  
  297.   Note that some or all of the above procedures should, in most cases,
  298.   be handled automatically by a make install. If so, the README or
  299.   INSTALL doc file will specify this.
  300.  
  301.   6.  First Example: Xscrabble
  302.  
  303.   Matt Chapman's Xscrabble seemed like a program that would be
  304.   interesting to have, since I happen to be an avid Scrabble[TM] player.
  305.   I downloaded it, uncompressed it,  and built it following the
  306.   procedure in the README file:
  307.  
  308.             xmkmf
  309.             make Makefiles
  310.             make includes
  311.             make
  312.  
  313.   Of course it did not work...
  314.  
  315.   ______________________________________________________________________
  316.   gcc -o xscrab -O2 -O -L/usr/X11R6/lib
  317.   init.o xinit.o misc.o moves.o cmove.o main.o xutils.o mess.o popup.o
  318.   widgets.o display.o user.o CircPerc.o
  319.   -lXaw -lXmu -lXExExt -lXext -lX11 -lXt -lSM -lICE -lXExExt -lXext -lX11
  320.   -lXpm -L../Xc -lXc
  321.  
  322.   BarGraf.o(.text+0xe7): undefined reference to `XtAddConverter'
  323.   BarGraf.o(.text+0x29a): undefined reference to `XSetClipMask'
  324.   BarGraf.o(.text+0x2ff): undefined reference to `XSetClipRectangles'
  325.   BarGraf.o(.text+0x375): undefined reference to `XDrawString'
  326.   BarGraf.o(.text+0x3e7): undefined reference to `XDrawLine'
  327.   etc.
  328.   etc.
  329.   etc...
  330.   ______________________________________________________________________
  331.  
  332.   I enquired about this in the comp.os.linux.x newsgroup, and someone
  333.   kindly pointed out that apparently the Xt, Xaw, Xmu, and X11 libs were
  334.   not being found at the link stage. Hmmm...
  335.  
  336.   There were two main Makefiles, and the one in the src directory caught
  337.   my interest. One line in the Makefile defined LOCAL_LIBS as:
  338.   LOCAL_LIBS = $(XAWLIB) $(XMULIB) $(XTOOLLIB) $(XLIB) Here were
  339.   references to the libs not being found by the linker.
  340.  
  341.   Looking for the next reference to LOCAL_LIBS, I saw on line 495 of
  342.   that Makefile:
  343.  
  344.              $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LOCAL_LIBS) $(LDLIBS)
  345.        $(EXTRA_LOAD_FLAGS)
  346.  
  347.   Now what were these LDLIBS?
  348.  
  349.              LDLIBS = $(LDPOSTLIB) $(THREADS_LIBS) $(SYS_LIBRARIES)
  350.        $(EXTRA_LIBRARIES)
  351.  
  352.   The SYS_LIBRARIES were:
  353.  
  354.         SYS_LIBRARIES = -lXpm -L../Xc -lXc
  355.  
  356.   Yes! Here were the missing libraries.
  357.  
  358.   Possibly the linker needed to see the LDLIBS before the LOCAL_LIBS...
  359.   So, the first thing to try was to modify the Makefile by transposing
  360.   the $(LOCAL_LIBS) and $(LDLIBS) on line 495, so it would now read:
  361.  
  362.                $(CCLINK) -o $@ $(LDOPTIONS) $(OBJS) $(LDLIBS) $(LOCAL_LIBS)
  363.        $(EXTRA_LOAD_FLAGS)                          ^^^^^^^^^^^^^^^^^^^^^^^
  364.  
  365.   I tried running make again with the above change, and lo and behold,
  366.   it worked this time. Of course,  Xscrabble still needed some fine
  367.   tuning and twiddling, such as renaming the dictionary and commenting
  368.   out some assert statements in one of the source files, but since then
  369.   it has provided me with many hours of pleasure.
  370.  
  371.   You may e-mail Matt Chapman <mailto:matt@belgarath.demon.co.uk>, and
  372.   download Xscrabble from his home page
  373.   <http://www.belgarath.demon.co.uk/programs/index.html>.
  374.  
  375.   ______________________________________________________________________
  376.          Scrabble is a registered trademark of the Milton Bradley Co., Inc.
  377.   ______________________________________________________________________
  378.  
  379.   7.  Second Example: Xloadimage
  380.  
  381.   This example poses an easier problem. The xloadimage program seemed a
  382.   useful addition to my set of graphic tools.  I copied the xloadi41.gz
  383.   file directly from the source directory on the CD included with the
  384.   excellent ``X User Tools'' book, by Mui and Quercia. As expected, tar
  385.   xzvf unarchives the files.  The make, however, produces a nasty-
  386.   looking error and terminates.
  387.  
  388.   ______________________________________________________________________
  389.   gcc -c -O -fstrength-reduce -finline-functions -fforce-mem
  390.   -fforce-addr -DSYSV  -I/usr/X11R6/include
  391.   -DSYSPATHFILE=\"/usr/lib/X11/Xloadimage\" mcidas.c
  392.  
  393.   In file included from /usr/include/stdlib.h:32,
  394.                    from image.h:23,
  395.                    from xloadimage.h:15,
  396.                    from mcidas.c:7:
  397.   /usr/lib/gcc-lib/i486-linux/2.6.3/include/stddef.h:215:
  398.   conflicting types for `wchar_t'
  399.   /usr/X11R6/include/X11/Xlib.h:74: previous declaration of
  400.   `wchar_t'
  401.   make[1]: *** [mcidas.o] Error 1
  402.   make[1]: Leaving directory
  403.   `/home/thegrendel/tst/xloadimage.4.1'
  404.   make: *** [default] Error 2
  405.   ______________________________________________________________________
  406.  
  407.   The error message contains the essential clue.
  408.  
  409.   Looking at the file image.h, line 23...
  410.  
  411.   ______________________________________________________________________
  412.          #include <stdlib.h>
  413.   ______________________________________________________________________
  414.  
  415.   Aha, somewhere in the source for xloadimage, wchar_t has been rede¡
  416.   fined from what was specified in the standard include file, stdlib.h.
  417.   Let us first try commenting out line 23 in image.h, as perhaps the
  418.   stdlib.h include is not, after all, necessary.
  419.  
  420.   At this point, the build proceeds without any fatal errors. The
  421.   xloadimage program functions correctly now.
  422.  
  423.   8.  Third Example: Fortune
  424.  
  425.   This final example requires some knowledge of C programming. The
  426.   majority of Linux software is written in C, and learning at least a
  427.   little bit of C would certainly be an asset for anyone serious about
  428.   software installation.
  429.  
  430.   The notorious fortune program displays up a humorous saying, a
  431.   "fortune cookie", every time Linux boots up. Unfortunately (pun
  432.   intended), attempting to build fortune on a Red Hat distribution with
  433.   a 2.0.30 kernel generates fatal errors.
  434.  
  435.   ______________________________________________________________________
  436.   ~/fortune# make all
  437.  
  438.   gcc -O2 -Wall -fomit-frame-pointer -pipe   -c fortune.c -o
  439.   fortune.o
  440.   fortune.c: In function `add_dir':
  441.   fortune.c:551: structure has no member named `d_namlen'
  442.   fortune.c:553: structure has no member named `d_namlen'
  443.   make[1]: *** [fortune.o] Error 1
  444.   make[1]: Leaving directory `/home/thegrendel/for/fortune/fortune'
  445.   make: *** [fortune-bin] Error 2
  446.   ______________________________________________________________________
  447.  
  448.   Looking at fortune.c, the pertinent lines are these.
  449.  
  450.   ______________________________________________________________________
  451.      if (dirent->d_namlen == 0)
  452.               continue;
  453.           name = copy(dirent->d_name, dirent->d_namlen);
  454.   ______________________________________________________________________
  455.  
  456.   We need to find the structure dirent, but it is not declared in the
  457.   fortune.c file, nor does a grep dirent show it in any of the other
  458.   source files. However, at the top of fortune.c, there is the following
  459.   line.
  460.  
  461.   ______________________________________________________________________
  462.   #include <dirent.h>
  463.   ______________________________________________________________________
  464.  
  465.   This appears to be a system library include file, therefore, the
  466.   logical place to look for dirent.h is in /usr/include.  Indeed, there
  467.   does exist a dirent.h file in /usr/include, but that file does not
  468.   contain the declaration of the dirent structure.  There is, however, a
  469.   reference to another dirent.h file.
  470.  
  471.   ______________________________________________________________________
  472.   #include <linux/dirent.h>
  473.   ______________________________________________________________________
  474.  
  475.   At last, going to /usr/include/linux/dirent.h, we find the structure
  476.   declaration we need.
  477.  
  478.   ______________________________________________________________________
  479.   struct dirent {
  480.           long            d_ino;
  481.           __kernel_off_t  d_off;
  482.           unsigned short  d_reclen;
  483.           char            d_name[256]; /* We must not include
  484.   limits.h! */
  485.   };
  486.   ______________________________________________________________________
  487.  
  488.   Sure enough, the structure declaration contains no d_namelen, but
  489.   there are a couple of "candidates" for its equivalent. The most likely
  490.   of these is d_reclen, since this structure member probably represents
  491.   the length of something and it is a short integer.  The other
  492.   possibility, d_ino, could be an inode number, judging by its name and
  493.   type. As a matter of fact, we are probably dealing with a "directory
  494.   entry" structure, and these elements represent attributes of a file,
  495.   its name, inode, and length (in blocks).  This would seem to validate
  496.   our guess.
  497.  
  498.   Let us edit the file fortune.c, and change the two d_namelen
  499.   references in lines 551 and 553 to d_reclen.  Try a make all again.
  500.   Success. It builds without errors. We can now get our "cheap thrills"
  501.   from fortune.
  502.  
  503.   9.  Where to Find Source Archives
  504.  
  505.   Now that you are eager to use your newly acquired knowledge to add
  506.   utilities and other goodies to your system, you may find them online
  507.   at the Linux Applications and Utilities Page
  508.   <http://www.redhat.com/linux-info/linux-app-list/linapps.html>, or on
  509.   one of the very reasonably priced CD ROM archives by Red Hat
  510.   <http://www.redhat.com/>, InfoMagic <mailto:orders@infomagic.com>, and
  511.   others.
  512.  
  513.   A comprehensive repository of source code is the comp sources UNIX
  514.   archive <ftp://ftp.vix.com/pub/usenet/comp.sources.unix/>.
  515.  
  516.   Much UNIX source code is posted on the alt.sources newsgroup. If you
  517.   are looking for particular source code packages, you may post on the
  518.   related alt.sources.wanted newsgroup.  Another good place to check is
  519.   the comp.os.linux.announce newsgroup.  To get on the Unix sources
  520.   <mailto:unix-sources@pa.dec.com> mailing list, send a subscribe
  521.   message there.
  522.  
  523.   Archives for the alt.sources newsgroup are at the following ftp sites:
  524.  
  525.   ╖  ftp.sterling.com/usenet/alt.sources/
  526.      <ftp://ftp.sterling.com/usenet/alt.sources/>
  527.  
  528.   ╖  wuarchive.wustl.edu/usenet/alt.sources/articles
  529.      <ftp://wuarchive.wustl.edu/usenet/alt.sources/articles>
  530.  
  531.   ╖  src.doc.ic.ac.uk/usenet/alt.sources/articles
  532.      <ftp://src.doc.ic.ac.uk/usenet/alt.sources/articles>
  533.  
  534.   10.  Final Words
  535.  
  536.   To sum up, persistence makes all the difference  (and a high
  537.   frustration threshold certainly helps). As in all endeavors, learning
  538.   from mistakes is critically important.  Each misstep, every failure
  539.   contributes to the body of knowledge that will lead to mastery of the
  540.   art of building software.
  541.  
  542.   11.  References and Further Reading
  543.  
  544.   BORLAND C++ TOOLS AND UTILITIES GUIDE, Borland International, 1992,
  545.   pp. 9-42.
  546.   [One of the manuals distributed with Borland C++, ver. 3.1. Gives
  547.   a fairly good intro to make syntax and concepts, using Borland's
  548.   crippled implementation for DOS.]
  549.  
  550.   DuBois, Paul: SOFTWARE PORTABILITY WITH IMAKE, O'Reilly and Associates,
  551.   1996, ISBN 1-56592-226-3.
  552.   [This is reputed to be the definitive imake reference, though I did not
  553.   have it available when writing this article.]
  554.  
  555.   Frisch, Aeleen: ESSENTIAL SYSTEM ADMINISTRATION, O'Reilly and
  556.   Associates, 1995, ISBN 1-56592-127-5.
  557.   [This otherwise excellent sys admin handbook has only sketchy coverage
  558.   of software building.]
  559.  
  560.   Lehey, Greg: PORTING UNIX SOFTWARE, O'Reilly and Associates, 1995, ISBN
  561.   1-56592-126-7.
  562.  
  563.   Mui, Linda and Valerie Quercia: X USER TOOLS, O'Reilly and Associates,
  564.   1994, ISBN 1-56592-019-8, pp. 734-760.
  565.  
  566.   Oram, Andrew and Steve Talbott: MANAGING PROJECTS WITH MAKE, O'Reilly
  567.   and Associates, 1991, ISBN 0-937175-90-0.
  568.  
  569.   Peek, Jerry and Tim O'Reilly and Mike Loukides: UNIX POWER TOOLS,
  570.   O'Reilly and Associates / Random House, 1997, ISBN 1-56592-260-3.
  571.   [A wonderful source of ideas, and tons of utilities you may end up
  572.   building from the source code, using the methods discussed in
  573.   this article.]
  574.  
  575.   Stallman, Richard M. and Roland McGrath: GNU MAKE, Free Software
  576.   Foundation, 1995, ISBN 1-882114-78-7.
  577.   [Should be required reading.]
  578.  
  579.   Welsh, Matt and Lar Kaufman: RUNNING LINUX, O'Reilly and Associates,
  580.   1996, ISBN 1-56592-151-8.
  581.   [Still the best overall Linux reference, though lacking in depth
  582.   in some areas.]
  583.  
  584.   And, of course, the man pages for make, imake, xmkmf, gcc, ldconfig,
  585.   gzip, tar, and patch.
  586.  
  587.